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INTRODUCTION 

The pharmaceutical industry has a demanding set of require- 
ments for process automation (PA). These requirements 
derive from the need for safe, pure, and effective medicines. 
Any implementation must also satisfy an extensive set of 
government regulations. Proper design and implementation 
of automation systems help to ensure a safe, predictable, 
high-quality, and low-cost supply of medication. 

There are many types of process software for the phar- 
maceutical industry. This chapter will emphasize the most 
common types of software that are used directly in PA. 
Supporting software for such things as instrument calibra- 
tion is also discussed here. 

Software for this industry must meet specific and far- 
reaching requirements. They must be well-designed, prop- 
erly implemented, and thoroughly validated. 

This chapter provides an introduction to many aspects of 
automation system design and implementation for the phar- 
maceutical industry with an emphasis on the validation of 
automation software. 


PARTICULAR NEEDS OF PHARMACEUTICAL INDUSTRY 

Government and quality requirements for the pharmaceuti- 
cal industry are more stringent than for other industries, 
and with good reason. The finished products are ingested or 
injected directly into people: often into the sick, the elderly, 
and young children. The consequences of quality problems 
are truly life-and-death, so every aspect of manufacture, 
including the PA, must be held to the highest of standards. 
As a result, the pharmaceutical products go through many 
phases (as shown in Figure 53.1) before they are introduced 
to the consumers. Each phase in this figure is supported 
by IT applications and appropriate software. But in this 
article, only the software in the manufacturing and produc- 
tion phase. 

Recognizing the need for these high standards, govern- 
ments have established regulations for the design, imple- 
mentation, maintenance, and evaluation of pharmaceutical 
processes. In the U.S. Code of Federal Regulations (CFR), 
the primary regulations are the following: 


• 21 CFR, Part 210 

• 21 CFR, Part 11 Electronic Records and Electronic 
Signatures 

Of course, other countries have similar, but different 
regulations. 

A primary focus of the regulations is “validation.” The 
concept of validation drives all aspects of pharmaceuti- 
cal production, including the PA. Simply put, validation is 
a process to ensure that all aspects of product manufacture 
are meeting their design specifications. This concept ranges 
from instrumentation to automated sequencing, to batch 
record-keeping. As one might expect, validation creates an 
enormous amount of paperwork. 

Because government regulations cannot possibly stay 
up to date with all of the practical issues of new technology, 
industry groups have formed to understand the technology, 
interpret the regulations, and suggest practical approaches. 
These groups have published a number of books to guide the 
implementation of automation. The most widely known is 
the good automated manufacturing practice (GAMP) guide 
series, including 

• GAMP Guide for Validation of Automated Systems 

• GAMP Good Practice Guide: Validation of Process 
Control Systems 

Of course, it is the responsibility of each manufacturer to 
ensure compliance with the regulations. Each company has 
its own standards, procedures, and quality control practices. 
So, automation software designs, implementations, and vali- 
dation procedures must comply with government regulations, 
industry standards, and company policies. 

Modern automation systems are largely software. From 
instrument firmware, to programmable logic controllers 
(PLCs), distributed control systems (DCSs), and human- 
machine interfaces (HMIs), many automation systems carry 
a wide variety of software. 

Furthermore, automation in the pharmaceutical indus- 
tries requires a level of security that is rivaled by few others. 
To ensure accurate records accountability, and when dealing 
with restricted substances and pathogens, specific security 
measures must be taken. This may include physical security 
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FIG. 53.1 

Pharmaceutical value chain. 

for automation hardware, as well as paper or electronic signa- 
tures, or even biometric confirmation. 

Pharmaceutical manufacturing is dominated by batch 
operations. Batch management software (BMS) plays a key 
role in modern pharmaceutical PA. 


• DCS software 

• Programmable logic controllers 

• Batch management software 

• Human-machine interfaces 

• Data historians 

• Instrumentation firmware and programming 

• Operating system 

• Networks 

Many other types of software are important to the implemen- 
tation of PA. They support the engineering, design, and main- 
tenance of automation systems, but will not be addressed in 
detail here. These include 


Validation 

The process of validating or qualifying a process involves a 
systematic, documented review of the final system against 
the design specifications. The qualification process is most 
often conceptually modeled using the GAMP-developed 
V-Model illustrated in Figure 53.2. The V-Model shows the 
typical steps and deliverables in an automation project, start- 
ing from top left, following down to the bottom of the chart, 
and then continuing up to the top right. Each activity or deliv- 
erable on the right-hand side of the “V” is used to validate the 
deliverable or activity on the left-hand side. 

The key point of the validation is that the overall system, 
and each individual component, are deliberately designed, 
and after implementation, are proven and documented to be 
exactly as designed. 

The key components of any validation or qualification 
activity are the documentation of design requirements fol- 
lowed by the verification that the finished system complies with 
those specifications. The GAMP Forum has developed widely 
accepted guidelines for the commissioning and qualification of 
automated systems. The guidelines are fairly generic, however, 
and require interpretation. There are many books and training 
courses to address the validation of automation systems. 

Validation requires clear documentation of every step in 
the process. From early process and design requirements, 
through to the final sign-off. It is important that strict docu- 
ment control procedures are followed. This includes strict 
version controls, and official signatures to accept each aspect 
of the design. 

Some document control software systems allow for 
electronic versions of documents, including collection of 
electronic signatures. While these systems add substantial 
overhead when first used, they can greatly simplify and auto- 
mate process design and validation. 


• Computer-aided design 

• Document management systems 

• Metrology/calibration record-keeping 

• Simulators and so on 

Classifications of Software 

A modern PA application may involve dozens of software 
systems, each from different vendors. The required level of 
validation has been a subject of heated debate over almost 
two decades. The results of these debates have largely been 
captured in the GAMP guides. 

The GAMP guide contains five levels of software to be 
addressed. These are as follows: 

• Category 1 — Infrastructure and operating systems 

• Category 2 — Firmware (discontinued as of GAMP 5) 

• Category 3 — Non-configured software 

• Category 4 — Configured software 

• Category 5 — “Bespoke” software 

Categories 1 through 3 are typically “Commercial Off the 
Shelf” (COTS) software. These are considered to have a 
lower level of risk, and therefore have less stringent validation 
requirements. Categories 4 and 5 have the higher risk levels, 
and therefore carry more stringent validation procedures. 

DCS and PLC programming are typically considered 
Category 5, while configuration of a data historian would 
likely be Category 4. 

A Category 5 system would require validation procedures 
such as vendor audits, fully detailed design documents such 
as a functional specification, user requirements, document 
and detailed design specification. Again, the GAMP guides 
are an excellent reference. 

GOOD ENGINEERING PRACTICES 


FORMS OF PROCESS AUTOMATION SOFTWARE 

For the purposes of this chapter, PA software includes the 
following: 


Good engineering practices should drive the design of every 
pharmaceutical PA system. As noted above, each step of 
the process must be clearly documented. Table 53.1, taken 
from “Automation Applications in Bio-pharmaceuticals,” 
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FIG. 53.2 

GAMP V-Model. 
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TABLE 53.1 

Common Engineering Documents for Process Automation [1] 


Documentation 

Description 


Process description, or 
process narrative 

User requirements 
specification (URS) 

Functional requirements 
specification (FRS) 

Detailed design 
specification (DDS) 

Process and instrumentation 
diagrams (P&IDS) 

Network diagrams 

Instrument list 


A very high-level text document, describing the operation of each part of the process. Usually includes a description of 
each process, the extent of automation, and the critical variables for control. 

The URS provides a basis for the design. It includes definition of operator interfaces, user interaction, alarming, and 
other HMI-related needs. The URS generally does not discuss “How” to accomplish the goals, but rather “What is the 
desired end-result.” 

The FRS includes details about exactly what the automation should do. It is common to include graphical representation 
of batch sequences, pseudo-code, decision points, discussion of company standards, and design requirements at a more 
detailed level than the URS. 

The DDS contains many details about the design of the automation system. From the DDS, a competent engineer 
should be able to build the automation and control system. The DDS may include (or refer to) additional detailed 
documents such as P&IDs, network diagrams, instrument list, etc. 

The staple design document of the process engineer and process control engineer. P&IDs show piping, vessels, 
instrumentation, and control strategies. It is important that there is strict version control on the P&IDs, and that 
everyone is working with the most current set. 

A network diagram should show information about physical installation as well as network addresses, switch settings, 
and other key design features. 

As in any automation project, it is critical to have an instrument list. At a minimum, the list should contain instrument 
tag names, descriptions, ranges, engineering units, and I/O locations. Critical instruments should be clearly identified. 


highlights some of the most common documentation 
requirements. 

Time Stamping 

Accurate production records require accurate date/time 
stamps. Achieving this is not as simple as one might pre- 
sume. Consider that every computer (including HMIs, LIMS, 
historian, and PLC/DCS) has its own, often independent 
clock. Establishing a single master clock can help to ensure 
that there are no inaccuracies in final batch records. 

It is also important to consider how you will handle time 
stamps in the case of daylight savings time events. 

PLCs and DCSs 

PLCs and DCSs are the primary control platform for most 
modern pharmaceutical processes. Once considered to be 
two completely different sorts of systems, PLCs and DCSs 
have come closer together, so that now many of these systems 
resemble a hybrid of the two worlds. Today, only very small 
or very specialized pharmaceutical applications use dedi- 
cated, single -loop, or microcontrollers instead of the more 
general-purpose PLC/DCS/Hybrid. 

PLC and DCS software is a mix of COTS, configurable 
software, and custom “bespoke” software. The system is 
responsible for sampling of instrument signals, determining 
control operations, switching valves, reporting alarms, and 
for communicating with various other systems, such as the 
HMI, the data historian, and batch records systems. 

Some of these features may be integrated within the PLC, 
while others are decidedly separate applications, running on 


separate computers. The complete automation application 
must be designed and validated. 

Modular Design 

Modular software design can greatly simplify the imple- 
mentation of automation in this industry. Software modules 
can be developed, validated, then duplicated and applied 
throughout a project or a plant. 

For example, modular code for a formulation tank can be 
applied to many tanks using the same BMS interface. If there 
are several formulation tanks, the additional engineering 
effort to create the software module can be paid for through 
reduction in validation effort. 

HMIs 

For smaller systems, dedicated COTS HMI hardware and 
software are often used. However, in larger applications, the 
HMI tends to be more complex in pharmaceuticals than it 
is in other industries. The need for higher security, for elec- 
tronic signatures, and for integration with laboratory infor- 
mation management system (LIMS) systems tends to drive 
these requirements. 

BATCH OPERATIONS 

Pharmaceutical processes tend to be heavily batch-oriented. 
Many reagents are prepared batch-wise in formulation areas. 
Bioreactors typically start with a batch phase. Some bioreac- 
tors continue complete batch-wise, while others have a con- 
tinuous harvest phase. Separations, such as centrifugation 
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and chromatographic separations are also completed batch- 
wise. Of course, clean-in-place (CIP) and steam-in-place 
(SIP) operations are also completed batch-wise. 

Batch-oriented PA requires a different set of equipment, a 
different style of automation, and software that is oriented to 
handle the batch-wise nature of the operation. The initiation, 
operation, completion, and record-keeping are often tied to a 
single batch production code. 

ISA Batch Standard 

ISA, the International Society of Automation, developed 
the S88 batch standards to help engineers, designers, and 
operations to manage batch systems. This standard estab- 
lishes a universal model for batch automation. This includes 
clear definition of both a “physical model” for equipment 
and a “procedural model” with definition of terms such 
as “batch,” “phase,” “step,” and “recipe.” Use of the S88 
model reduces miscommunications and errors in design and 
implementation. 

Sequential Function Charts 

Sequential function charts (SFCs) provide a graphical tool for 
documenting batch operations. Each batch operation, step, 
and transitions are illustrated in the SFC format. An example 
of an SFC is shown in Figure 53.3. 

SFCs make an excellent tool for automation design 
reviews. They can provide a common language for scientists, 
operators, and automation engineers. 


Batch Management Software 

BMS oversees the lower-level automation system to produce 
pharmaceutical products. The BMS is typically responsible 
for the high-level recipes, batch timing, some record-keep- 
ing, security, and for making calls to the lower-level control 
systems. 

Batch operations go through many modes, or “states.” 
The S88 model defines these states and the transitions 
between them in using a standard model. Figure 53.4 shows 
the S88 states and their transitions. 

Configuration and programming of a BMS is a spe- 
cialized skill. Some automation providers have dedicated 
resources to this task. It is highly recommended that an expe- 
rienced BMS automation provider is used. 


ELECTRONIC RECORDS AND ELECTRONIC SIGNATURES 

As mentioned above, regulations require detailed produc- 
tion records and specific signature approvals for production 
records. It seems a natural request of the automation system 
to fulfill these duties. However, traditional computer security, 
databases, and industrial automation systems have had only 
limited security capabilities. 

In the United States, electronic records and electronic 
signatures are covered by a special part of the regulations, 
21 CFR Part 11. This regulation states the overall require- 
ments to ensure that records are captured accurately, and 
maintained securely. 
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FIG. 53.3 

An example sequential function chart. 
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FIG. 53.4 

An S88 State Diagram. 

Like other parts of the regulations. Part 11 does not pro- 
vide a lot of detail about how to achieve the requirements. 
However, most interpretations will confirm the need for 
physical and electronic security (e.g., passwords), as well as 
detailed audit trails for any modifications to the stored data. 

HVAC SYSTEM AUTOMATION 

Heating, Ventilation, and Air Conditioning (HVAC) are often 
considered part of the PA for pharmaceutical. To prevent 
cross-contamination, or to contain pathogens, it is important 
to maintain differential pressure between production suites. 
Many process operations are highly temperature sensitive. 
Also, gowning requirements may lead to uncomfortable 
working conditions unless the HVAC system set points are 
adjusted. 

It is typical for pharmaceutical production suites to have 
HVAC systems capable of maintaining temperature, humid- 
ity, and pressure to within tight limits in each room. 

Again, record-keeping is important. HVAC control sys- 
tems are typically connected to historian devices, whether 
simple chart recorders or more complex computer-based 
historians. 


CONCLUSIONS AND COMMENTS 

Pharmaceutical automation applications require a higher 
level of planning, engineering design, documentation, and 
commissioning than do those of most other industries. It is 
important to use a carefully thought-out approach to ensure a 
good design that can be validated. 

All aspects of PA software, from the simplest ladder logic 
to the most complex batch recipe management schemes are 
subject to the rigorous design, documentation, and commis- 
sioning processes. The added effort and expense provide 
considerable incentives to simplify software design and sys- 
tem architecture. In fact, this added effort and expense may 
likely prevent the automation of some systems. 

The reader is strongly encouraged to pursue further in- 
depth reading form the books listed in the bibliography. 
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